Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@front/src/config/i18n/de.json`:
- Around line 981-983: The translation key "connectionUrl" currently opens a
user-provided URL in a new tab using target="_blank" and must include
rel="noopener noreferrer" to prevent the opened page from accessing
window.opener; update the "connectionUrl" value (the string containing the
anchor tag) to add rel="noopener noreferrer" to the <a> element while preserving
the existing href and target attributes so the link remains functional and safe.

In `@front/src/config/i18n/en.json`:
- Line 876: The translation string "connectionUrl" contains an external anchor
with target="_blank" but lacks rel="noopener noreferrer"; update the value for
the "connectionUrl" key so the anchor tag becomes <a href="{{url}}"
target="_blank" rel="noopener noreferrer"> (i.e., add rel="noopener noreferrer"
to the anchor) to match other external links and avoid introducing an opener
relationship.

In `@front/src/config/i18n/fr.json`:
- Line 1111: The translation string "connectionUrl" currently opens an external
link with target="_blank" but omits rel attributes; update the value for the
"connectionUrl" key to include rel="noopener noreferrer" in the anchor tag so
the external page cannot access window.opener (i.e., modify the string for the
"connectionUrl" key to add rel="noopener noreferrer" to the <a> tag).

In `@front/src/routes/integration/all/zigbee2mqtt/device-page/actions.js`:
- Around line 46-49: The action currently fails entirely if the discovered
devices call errors; wrap the second Promise
(state.httpClient.get('/api/v1/service/zigbee2mqtt/discovered', {
filter_existing: false })) in a try/catch or resolve it separately so that
zigbee2mqttsReceived still returns; set discoveredDevices to an empty array on
error and only attach ieeeAddress when discoveredDevices contains a match (use
the existing discoveredDevices variable and the zigbee2mqttsReceived result),
thereby preserving loaded devices even when discovery/IEEE enrichment is
unavailable.
- Around line 13-27: Clear any stale z2mUrl before attempting to load setup and
DRY the logic into a shared helper: in getZ2mUrl (and the duplicate in
discover-page/actions.js) immediately call store.setState({ z2mUrl: undefined })
or use a shared async helper (e.g., fetchZ2mUrlFromSetup) that performs
state.httpClient.get('/api/v1/service/zigbee2mqtt/setup'), returns the resolved
z2mUrl or undefined, and then call store.setState({ z2mUrl }) with that result;
replace the duplicated URL-construction branches in getZ2mUrl and the
discover-page action with a single call to the helper so both pages consistently
clear stale values and set the new z2mUrl only on success.

In `@front/src/routes/integration/all/zigbee2mqtt/device-page/Zigbee2mqttBox.jsx`:
- Around line 169-174: The IEEE address input in Zigbee2mqttBox.jsx is using the
disabled attribute which prevents focus and copying; change the input rendering
that references props.device.ieeeAddress to use the readOnly attribute instead
of disabled (i.e., replace disabled with readOnly on the input element) so the
value remains non-editable but selectable/focusable for support/debug flows.

In
`@front/src/routes/integration/all/zigbee2mqtt/discover-page/DiscoveredBox.jsx`:
- Around line 134-152: The device URL built for opening Zigbee2MQTT is missing
the required tab segment; update the href construction that uses z2mUrl and
ieeeAddress (in the DiscoveredBox component where
href={`${z2mUrl}/#/device/0/${ieeeAddress}`} is built) to append a default tab
(e.g. `/info`) so it becomes `${z2mUrl}/#/device/0/${ieeeAddress}/info`; apply
the same fix to the analogous href in Zigbee2mqttBox.jsx to ensure both links
include the tab segment.

In `@server/services/zigbee2mqtt/utils/convertDevice.js`:
- Line 12: The server is destructuring device.ieee_address but consumers expect
device.ieeeAddress; update the destructuring to capture ieee_address as
ieeeAddress (e.g., const { friendly_name: name, definition = {}, ieee_address:
ieeeAddress } = device) and ensure the returned object from convertDevice
includes the ieeeAddress property (also fix the object construction around the
block that currently maps properties at lines referenced as 25-27) so the
emitted device has ieeeAddress available for the UI.

---

Outside diff comments:
In `@front/src/routes/integration/all/zigbee2mqtt/setup-page/index.js`:
- Around line 45-53: The z2mUrl state is only set for MQTT_MODE.LOCAL and never
derived from configuration.z2mFrontendUrl, so remote setups leave z2mUrl stale;
update the logic that sets z2mUrl (the block that currently checks
this.props.session.gatewayClient and MQTT_MODE.LOCAL) to also derive z2mUrl from
configuration.z2mFrontendUrl when present, and ensure the same derivation is
applied after save/update actions (the code paths around saving the
configuration) so z2mUrl is refreshed whenever configuration is loaded or saved;
reference the state key z2mUrl, the configuration object, and MQTT_MODE.LOCAL
and z2mFrontendUrl when making the change.

---

Nitpick comments:
In `@front/src/routes/integration/all/zigbee2mqtt/discover-page/actions.js`:
- Around line 10-25: Duplicate logic in getZ2mUrl should be extracted into a
shared Zigbee2MQTT helper: create a new helper function (e.g., resolveZ2mUrl or
getZ2mUrlFromConfig) that accepts the same inputs used here (state.httpClient,
state.session, config.localApiUrl, and store.setState or return value) and
encapsulates the URL normalization and store-setting logic currently in
getZ2mUrl; export that helper and replace the inline getZ2mUrl implementations
in both front/src/routes/integration/all/zigbee2mqtt/discover-page/actions.js
and device-page/actions.js to call the shared function (or await its result and
then set store state consistently), ensuring you preserve the existing behavior
for local vs external modes and the case where z2mUrl remains undefined.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@front/src/routes/integration/all/zigbee2mqtt/device-page/actions.js`:
- Around line 13-27: The getZ2mUrl function currently leaves a stale z2mUrl in
the store if the HTTP request fails or returns no usable URL; before calling
state.httpClient.get('/api/v1/service/zigbee2mqtt/setup') clear the stored value
(e.g., call store.setState({ z2mUrl: undefined })) so the link is removed, then
only call store.setState to populate z2mUrl inside the existing success branches
(where configuration.Z2M_MQTT_MODE === 'local' and the external branch) and do
not set it in the catch block.
- Around line 43-46: The code currently treats the discovered devices fetch as a
hard dependency by using
Promise.all([state.httpClient.get('/api/v1/service/zigbee2mqtt/device',
options), state.httpClient.get('/api/v1/service/zigbee2mqtt/discovered', {
filter_existing: false })]) which causes the whole load to fail if the
discovered route errors; change this to allow enrichment to degrade gracefully
by either using Promise.allSettled or catching the discoveredDevices promise and
falling back to an empty array ([]) so zigbee2mqttsReceived still loads and you
can attach ieee_address only when discoveredDevices is available (reference
symbols: zigbee2mqttsReceived, discoveredDevices, Promise.all,
state.httpClient.get('/api/v1/service/zigbee2mqtt/discovered')).

In
`@front/src/routes/integration/all/zigbee2mqtt/discover-page/DiscoveredBox.jsx`:
- Line 142: The generated Zigbee2MQTT device link is missing the required tab
segment; update the href template in DiscoveredBox.jsx (the expression using
z2mUrl and ieee_address) so it builds
`${z2mUrl}/#/device/0/${ieee_address}/info` (i.e., append `/info` to the
existing path) to match the Z2M frontend route format.

---

Nitpick comments:
In
`@front/src/routes/integration/all/zigbee2mqtt/discover-page/DiscoveredBox.jsx`:
- Around line 136-139: The IEEE address input lacks an id/for pairing for
accessibility; update the label and input in the DiscoveredBox component to
follow the same pattern used by other fields (e.g., name_${deviceIndex},
room_${deviceIndex}). Add a unique id for the input (such as
`ieee_${deviceIndex}` or similar based on `deviceIndex`) and set the label's
htmlFor/for attribute to that id so the label is correctly associated with the
`ieee_address` input. Ensure the id value is unique per device instance and use
the same `deviceIndex` variable used elsewhere in this component.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In
`@front/src/routes/integration/all/zigbee2mqtt/discover-page/DiscoveredBox.jsx`:
- Line 142: The device link built in DiscoveredBox.jsx currently uses
href={`${z2mUrl}/#/device/0/${ieee_address}`} which omits the expected tab
segment; update the href to include a default tab (e.g., `/info`) so deep-links
become `${z2mUrl}/#/device/0/${ieee_address}/info`; locate the JSX anchor using
z2mUrl and ieee_address and append the `/info` segment (or use a DEFAULT_Z2M_TAB
constant and reference that) to ensure compatibility with Windfront routes.